The steady-state speedup is nice, but this increases tile load time a bit and it makes tiles much larger. I think I can fix both of those without impacting the steady-state performance. I'm working on it now.

Sounds good, thanks. Why does it increase load time? Web worker transfer?

As for tile size, my only concern would be L2 cache pollution (I actually think I am running into this elsewhere for setting uniforms) given the tile itself is tiny compared to the renderer resources.

Why does it increase load time?

Because the first time we see a tile, we're now building up a giant shader string and then looking that up in the shader cache. Previously we built a smaller key and looked that up. It should be possible to avoid string lookups entirely.

my only concern would be L2 cache pollution

Yeah, exactly. We end up looking at a lot more tiles during tile selection than we actually end up rendering. I don't know if the size increase ends up having a measurable impact on the performance due to cache pollution, but as long as we're optimizing this up we might as well optimize it a bit better, since it's not much harder.

Ah, I almost keep the older cache too, but a non-string lookup sounds good.

As for L2, I've thought about - in general - organizing objects so that the properties needed for traversal are tightly defined with a pointer to another object with all the other properties. I believe this is a common old-school game technique for fitting as many objects as possible into cache lines. I haven't tried this because we have bigger fish to fry, but keeping the tile tight for now sounds good. Just pack them into an int or two or whatever.

Ok this should be in good shape now. New tiles can now get an existing shader without any string concatenations or comparisons. GlobeSurfaceTile only has one new field. Verifying that a tile's existing shader is still good requires three comparisons plus a bunch of bit operations, which should be better than a bunch of comparisons. Also, enabling/disabling lighting on the fly should actually work now. I believe it was broken in the previous version of this pull request.

Someone else should probably merge this now that I've changed it pretty significantly.

All looks good, thanks! By the way, is it possible to use the squared distance instead for computeDistanceToTile? That is another hot spot.

By the way, is it possible to use the squared distance instead for computeDistanceToTile?

Yes, almost certainly. Actually the entire screenSpaceError computation can be optimized quite a bit. I think Insight3D precomputes the switching-distance-squared for each tile and just compares that, rather than doing any math per frame. I'm sure we can do the same. When I originally wrote it, the profiler showed that a negligible amount of time was spent there, so I didn't spend any time optimizing it. That has changed since, maybe because WebGL implementations have gotten faster or something.

Want to add it to the roadmp (#526) - or just do it! 👍